<!DOCTYPE html>
<meta charset="utf-8">
<title>CSS Scroll Snapping Level 1 Disposition of Comments for 2015-03-26 WD</title>
<style type="text/css">
  pre { border: solid thin silver; padding: 0.2em; white-space: normal; }
  pre > span { display: block; white-space: pre; }
  :not(pre).a  { background: lightgreen }
  :not(pre).d  { background: lightblue  }
  :not(pre).oi { background: yellow     }
  :not(pre).r  { background: orange     }
  :not(pre).fo { background: red        }
  .open   { border: solid red; }
  :target { box-shadow: 0.25em 0.25em 0.25em;  }
</style>

<h1>CSS Scroll Snapping Level 1 Disposition of Comments for 2015-03-26 WD</h1>

<p>Dated Draft: <a href="http://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/">http://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/</a>

<p>Editor's Draft: <a href="http://dev.w3.org/csswg/css-scroll-snap-1/">http://dev.w3.org/csswg/css-scroll-snap-1/</a>

<p>The following color coding convention is used for comments:</p>

<ul>
 <li class="a">Accepted or Rejected and positive response
 <li class="r">Rejected and no response
 <li class="fo">Rejected and negative response
 <li class="d">Deferred
 <li class="oi">Out-of-Scope or Invalid and not verified
</ul>

<p class=open>Open issues are marked like this</p>

<p>An issue can be closed as <code>Accepted</code>, <code>OutOfScope</code>,
<code>Invalid</code>, <code>Rejected</code>, or <code>Retracted</code>.
<code>Verified</code> indicates commentor's acceptance of the response.</p>
<h2 id=scroll-snapping-geometry>Scroll Snapping Geometry</h2>
<pre class=' a' id='issue-1'>
<span>Issue 1. <a href='#issue-1'>#</a></span>
<span>Summary:  Snapping should be element-based</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html</a> (roc)</span>
<span>    Snap offsets should be derived automatically from the layout</span>
<span>    if the descendants of the scrolling container, so that changes to</span>
<span>    that layout don't require manual updating of some property set on</span>
<span>    the container.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Oct/0570.html'>https://lists.w3.org/Archives/Public/www-style/2013Oct/0570.html</a> (tab)</span>
<span>    Need to snap to elements.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0816.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0816.html</a> (roc)</span>
<span>    I feel that the focus on length-based properties in the draft is a mistake</span>
<span>    and starting with a focus on element boxes makes more sense. Hard-coding</span>
<span>    lengths makes for fragile and non-responsive designs.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015May/0282.html'>https://lists.w3.org/Archives/Public/www-style/2015May/0282.html</a> (NYC 2015)</span>
<span>    Authors want snapping to boxes, not having to do JS math against layout</span>
<span>Solution: scroll-snap-coordinate/destination or scroll-snap-area/align</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-2'>
<span>Issue 2. <a href='#issue-2'>#</a></span>
<span>Summary:  Interaction with transforms</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html</a> (roc)</span>
<span>    Define interaction with transforms</span>
<span>Solution: rakow specifies that coordinates of snap point get transformed with element</span>
<span>Solution: TF specifies that scroll-snap-area originates as bounding box of transformed border/margin-box</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-3'>
<span>Issue 3. <a href='#issue-3'>#</a></span>
<span>Summary:  Handle overly-large elements properly</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html</a> (roc)</span>
<span>    Allow UAs to not snap when box is larger than scroll-port</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html'>https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html</a> (roc)</span>
<span>    Summary:  Need to be able to scroll an overly-large element without it forcing a snap, even if it's "mandatory".</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html</a> (rakow)</span>
<span>    Use case: Freely scrolling areas within "boundaries" that resist scrolling</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0008.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0008.html</a> (roc)</span>
<span>    Mandatory snapping should be disabled when box fills viewport</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html</a> (rakow)</span>
<span>    Changing behavior based on size is confusing</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html</a></span>
<span>    Authors are dumb when it comes to varying size viewports, we have to help users</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html'>https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html</a> (TPAC 2014)</span>
<span>    Need to consider varying screen sizes, esp wrt mandatory snap points</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015May/0282.html'>https://lists.w3.org/Archives/Public/www-style/2015May/0282.html</a> (NYC 2015)</span>
<span>    Current proposal doesn't handle varying viewport sizes</span>
<span>Solution: Making all views in which element fills viewport a valid snap position</span>
<span>          <a href='https://drafts.csswg.org/css-scroll-snap/#scroll-snap-align'>https://drafts.csswg.org/css-scroll-snap/#scroll-snap-align</a></span>
<span class="a">Closed:   Accepted by TF</span></pre>
<pre class=' a' id='issue-4'>
<span>Issue 4. <a href='#issue-4'>#</a></span>
<span>Summary:  Need a way to snap to the center of an element.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0303.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0303.html</a> (rakow)</span>
<span>Solution: scroll-snap-destination: center + scroll-snap-coordinate: center / scroll-snap-align: center</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-5'>
<span>Issue 5. <a href='#issue-5'>#</a></span>
<span>Summary:  Need a way to snap while "peeking" the next/prev thing a little bit.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0303.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0303.html</a> (rakow)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html</a> (roc)</span>
<span>    Use offsets plus box-name</span>
<span>Solution: scroll-snap-destination: 10px [only works in one direction] / scroll-snap-area: 10px</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-6'>
<span>Issue 6. <a href='#issue-6'>#</a></span>
<span>Summary:  Define box-based scroll-snap with per-element padding/offsets</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0226.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0226.html</a></span>
<span>Solution: scroll-snap-area</span>
<span class="a">Closed:   Accepted by TF</span>
<span>Resolved: <a href='https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html'>https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html</a></span></pre>
<pre class=' a' id='issue-7'>
<span>Issue 7. <a href='#issue-7'>#</a></span>
<span>Summary:  Make sure this works with box-sizing, and uses consistent terminology.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html</a> (Seattle F2F)</span>
<span>Solution: scroll-snap-area</span>
<span class="a">Closed:   Accepted by TF</span></pre>
<pre class=' a' id='issue-8'>
<span>Issue 8. <a href='#issue-8'>#</a></span>
<span>Summary:  scroll-snap-coordinate needs to allow specifying which box to use (margin vs border)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html</a> (roc)</span>
<span>Solution: scroll-snap-area</span>
<span class="a">Closed:   Accepted by TF [later dropped]</span></pre>
<pre class=' a' id='issue-9'>
<span>Issue 9. <a href='#issue-9'>#</a></span>
<span>Summary:  Add scroll snappoint repetition length</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html</a> (tab)</span>
<span>    I'd add an additional property for setting explicit snap points</span>
<span>    in addition to the implicit points coming from the children,</span>
<span>    probably with a repetition syntax so you can set up a snap point every 100px or whatever.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0253.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0253.html</a> (roc)</span>
<span>    I can't think of any [use cases] that wouldn't work better</span>
<span>    using scroll-snap-edge on descendant elements.</span>
<span class="a">Closed:   Accepted</span>
<span>Solution: scroll-snap-points-x/y: repeat(&lt;length>)</span></pre>
<pre class=' a' id='issue-10'>
<span>Issue 10. <a href='#issue-10'>#</a></span>
<span>Summary:  Remove scroll-snap-points-x/y: repeat() in favor of element-snapping</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html</a> (roc)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html</a> (rakow)</span>
<span>    snap-interval is needed for paging</span>
<span>    Use case: Handle redfin filmstrip (repeat 9 photos, 10 photos visible)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html</a> (roc)</span>
<span>    [don't think this is user-friendly; your use case is invalid]</span>
<span></span>
<span>    AFAICT the strip is not actually scrollable using any UA gestures, but only</span>
<span>    using those buttons, so scroll snapping isn't relevant here.</span>
<span></span>
<span>    If we consider a slightly different example where the strip is scrollable</span>
<span>    via UA gestures as well as the buttons, I don't think you'd actually want</span>
<span>    to snap to container-sized boundaries; that would just annoy users who try</span>
<span>    to scroll a few more images into view and find they can't. Instead you'd</span>
<span>    want to snap to the margin-box of each image. Those buttons are just</span>
<span>    page-left/page-right controls and could be implemented just the same as</span>
<span>    they are today, although we might want to extend CSSOM ScrollOptions with a</span>
<span>    "snap" parameter so that the button event handler can opt into snapping</span>
<span>    when calling scrollBy so it snaps to an image margin-box edge.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0062.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0062.html</a> (roc)</span>
<span>    Use container.scrollBy(container.clientWidth, 0, {behavior:"smooth"})</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015May/0282.html'>https://lists.w3.org/Archives/Public/www-style/2015May/0282.html</a></span>
<span>    Repeat seems unnecessary</span>
<span>Solution: Drop scroll-snap-x/y: repeat()</span>
<span class="a">Closed:   Accepted</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' a' id='issue-11'>
<span>Issue 11. <a href='#issue-11'>#</a></span>
<span>Summary:  Multiple snap points per element</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html</a> (Seattle F2F)</span>
<span>    Rossen: photos with faces</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html</a> (rakow)</span>
<span>    Elements with multiple "points of interest" that can all be snapped to?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0594.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0594.html</a> (roc)</span>
<span>    Use invisible elements representing the points of interest</span>
<span>    Or image map &lt;area> tags? Can we define how those snap? -- fantasai</span>
<span>Solution: Add elements to represent points of interest.</span>
<span class="a">Closed:   Accepted</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' oi' id='issue-12'>
<span>Issue 12. <a href='#issue-12'>#</a></span>
<span>Summary:  Allow snapping between multicol columns</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0257.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0257.html</a> (fremy)</span>
<span>    Authors might want to snap per-column</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0260.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0260.html</a> (roc)</span>
<span>    Create a ::column pseudo-element, snap to that</span>
<span>Solution:  Use ::column pseudo-element, deferred to css-pseudo</span>
<span class="oi">Closed:    OutOfScope</span>
<span>Resolved:  TPAC 2015</span></pre>
<pre class=' r' id='issue-13'>
<span>Issue 13. <a href='#issue-13'>#</a></span>
<span>Summary:  Snapping to grid lines?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0064.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0064.html</a> (fremy)</span>
<span>Solution:  Snap to elements (don't see strong use case for when there aren't any)</span>
<span class="r">Closed:    Rejected</span>
<span>Resolved:  TPAC 2015</span></pre>
<pre class=' d' id='issue-14'>
<span>Issue 14. <a href='#issue-14'>#</a></span>
<span>Summary:  Use case for baseline aligned snap position</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html</a></span>
<span class="d">Closed:    Deferred to future, but consider how it would work with -align</span></pre>
<pre class=' a' id='issue-15'>
<span>Issue 15. <a href='#issue-15'>#</a></span>
<span>Summary:  Don't see use case for scroll-snap-points-x/y given elements</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>    I'm not sure that scroll-snap-points-x/y is really needed if we have</span>
<span>    good support for scrolling to element edges. Is there a use-case where it's</span>
<span>    useful to be able to specify snap-points that are not at the edge of some</span>
<span>    element's box (or some fixed offset thereof)?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html</a> (roc)</span>
<span>    No use-case for scroll-snap-points-x/y. Just drop it.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html</a> (roc)</span>
<span>    I still think a case has not been made for scroll-snap-points-x/y to</span>
<span>    support any value other than "elements", so we should get rid of it.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html</a> (rakow)</span>
<span>    Response: Removed scroll-snap-points-x/y offset list</span>
<span>Solution: Removed offset list</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-16'>
<span>Issue 16. <a href='#issue-16'>#</a></span>
<span>Summary:  Should apply to more than just block-level boxes</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html</a> (dbaron)</span>
<span>Solution: Applies to all elements</span>
<span class="a">Closed:   Accepted</span>
<span>Resolved: TPAC 2015</span></pre>
<h2 id=scroll-snapping-triggers>Scroll Snapping Triggers</h2>
<pre class=' a' id='issue-20'>
<span>Issue 20. <a href='#issue-20'>#</a></span>
<span>Summary:  Define that scroll gestures don't snap "backwards"</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html</a> (roc)</span>
<span>    Guideline that scroll gestures with definite direction</span>
<span>    do not scroll backwards to snap point</span>
<span>Solution: Added guideline to <a href='https://drafts.csswg.org/css-scroll-snap/#choosing'>https://drafts.csswg.org/css-scroll-snap/#choosing</a></span>
<span class="a">Closed:   Accepted by TJ</span></pre>
<pre class=' a' id='issue-21'>
<span>Issue 21. <a href='#issue-21'>#</a></span>
<span>Summary:  Which user gestures are snapped?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html</a> (roc)</span>
<span>    Define that all user scroll gestures are affected by snapping</span>
<span>Solution: Clarified that all scroll gestures are snapped</span>
<span class="a">Closed:   Accepted</span>
<span class="a">Verified: by unarchived email from roc</span></pre>
<pre class=' a' id='issue-22'>
<span>Issue 22. <a href='#issue-22'>#</a></span>
<span>Summary:  Do layout changes resnap?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html</a> (roc)</span>
<span>    Define that layout changes do not trigger resnapping</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html</a></span>
<span>    What should we do when when we're snapped, then the element moves? </span>
<span>    For proximity, maybe okay to do nothing, but mandatory should re-snap.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html</a> (rakow)</span>
<span>    Spec update: Mandatory snap points must resnap when layout shifts</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html'>https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html</a> (roc)</span>
<span>    Concern wrt implementability of resnapping to layout changes</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0452.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0452.html</a> (rakow)</span>
<span>    Response: No, really, we need to resnap always otherwise authors</span>
<span>    have to do it themselves manually.</span>
<span>Solution: Require resnapping <a href='https://drafts.csswg.org/css-scroll-snap/#snap-type'>https://drafts.csswg.org/css-scroll-snap/#snap-type</a></span>
<span class="a">Closed:   Accepted</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' a' id='issue-23'>
<span>Issue 23. <a href='#issue-23'>#</a></span>
<span>Summary:  Resnap reaction to deleted snappoint?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0458.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0458.html</a> (roc)</span>
<span>    What happens if that snap point ceases to exist?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0479.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0479.html</a> (rakow)</span>
<span>    UA-defined, usually nearest or next element is good</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Aug/0000.html'>https://lists.w3.org/Archives/Public/www-style/2015Aug/0000.html</a> (roc, tab)</span>
<span>    Need to specify which exactly, for interop</span>
<span class="a">Closed:   Accepted</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' a' id='issue-24'>
<span>Issue 24. <a href='#issue-24'>#</a></span>
<span>Summary:  When do layout changes trigger resnapping?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0458.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0458.html</a> (roc)</span>
<span>    When does this auto-snapping occur? On every layout?</span>
<span>    Including layouts that occur during script execution?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0479.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0479.html</a> (rakow)</span>
<span>    After OM/layout/display completes, provided no active scroll event</span>
<span class="a">Closed:   Accepted by TF</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' a' id='issue-25'>
<span>Issue 25. <a href='#issue-25'>#</a></span>
<span>Summary:  Is DOM script-scrolling snapped?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html</a> (roc)</span>
<span>    Define whether script-driven scrolling is affected by snapping</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html'>https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html</a> (roc)</span>
<span>    Clarify whether JS scrollTop setting causes resnapping</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0230.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0230.html</a> (bfulgham)</span>
<span>    Spec doesn't say whether scrollTo/scrollLeft/scrollTop/scrollIntoView snap</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0231.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0231.html</a> (roc)</span>
<span>    No snapping for DOM Apis, but add 'snap' value to ScrollOptions</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html</a> (rakow)</span>
<span>    Always snap to snappoints</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html</a> (majid)</span>
<span>    Scroll APIs need to be able to evade snap restrictions</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0046.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0046.html</a> (roc)</span>
<span>    Having some JS operations snap and others not is weird</span>
<span>    (Changing layout and script-scrolling should act the same.)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0452.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0452.html</a> (rakow)</span>
<span>    Response: No, really, we need to resnap always otherwise authors</span>
<span>    have to do it themselves manually.</span>
<span>Solution: Scroll positions are always snapped</span>
<span class="a">Closed:   Accepted</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' ' id='issue-26'>
<span>Issue 26. <a href='#issue-26'>#</a></span>
<span>Summary:  Add 'snap' parameter to CSSOM ScrollOptions (make not-snapping default)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html</a></span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0231.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0231.html</a></span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0085.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0085.html</a></span>
<span class="">Closed:   Rejected, due to resolution of previous issue</span></pre>
<pre class=' r' id='issue-27'>
<span>Issue 27. <a href='#issue-27'>#</a></span>
<span>Summary:  Add some DOM APIs</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0375.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0375.html</a></span>
<span>    [no clue what stuff, Tab you'll have to elaborate]</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0384.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0384.html</a> (roc)</span>
<span>    You can read and write the scroll position using scrollLleft/scrollTop and</span>
<span>    the scroll event. In principle this is enough information to do whatever</span>
<span>    you need. Some convenience APIs might be useful, e.g. to compute the</span>
<span>    possible snapping destinations when scrolling in a particular direction.</span>
<span>Solution: scrollTop and scrollLeft</span>
<span class="r">Closed:   Rejected</span></pre>
<pre class=' d' id='issue-28'>
<span>Issue 28. <a href='#issue-28'>#</a></span>
<span>Summary:  Might be nice to have API to get snap destinations</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0384.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0384.html</a> (roc)</span>
<span>    Some convenience APIs might be useful,</span>
<span>    e.g. to compute the possible snapping destinations</span>
<span>    when scrolling in a particular direction.</span>
<span class="d">Closed:   Deferred</span>
<span>Resolved: TPAC 2015</span></pre>
<h2 id=syntax-and-property-interactions>Syntax and Property Interactions</h2>
<pre class=' a' id='issue-40'>
<span>Issue 40. <a href='#issue-40'>#</a></span>
<span>Summary:  Use flow-relative logical syntax</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html</a> (tab)</span>
<span>    Should use logical directions for property/value naming</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0253.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0253.html</a> (roc)</span>
<span>    Layout isn't always logical</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0258.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0258.html</a> (howcome)</span>
<span>    Axis isn't usually defined by writing mode, but direction within axis is</span>
<span class="a">Closed:   Accepted by TF</span></pre>
<pre class=' a' id='issue-https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html'>
<span>Issu 41.</span>
<span>Summary:  Add "none" value to scroll-snap-points-x/y</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html</a> (roc)</span>
<span>    Given element-based snapping, need ability to say "none" in scroll-snap-points-x/y</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html</a> (roc)</span>
<span>    Add "none" value to scroll-snap-points-x/y</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html</a> (rakow)</span>
<span>    Added.</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class='open ' id='issue-42'>
<span>Issue 42. <a href='#issue-42'>#</a></span>
<span>Summary:  Shorten "scroll-snap-type" to "scroll-snap"?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html</a> (roc)</span>
<span>    scroll-snap-type is too verbose. Shorten to scroll-snap?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Nov/0328.html'>https://lists.w3.org/Archives/Public/www-style/2015Nov/0328.html</a> (fantasai)</span>
<span>    Various shorthanding options</span>
<span class="">Open:     Need more feedback on the proposals.</span></pre>
<pre class=' a' id='issue-43'>
<span>Issue 43. <a href='#issue-43'>#</a></span>
<span>Summary:  "snappoints" is a misnomer, since you're usually snapping to edge</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html</a> (roc)</span>
<span>    Change name to css-scrollsnap, as we're not snapping points.</span>
<span>Solution: css-scroll-snap shortname</span>
<span class="a">Closed:   Accepted by TF</span></pre>
<pre class=' r' id='issue-44'>
<span>Issue 44. <a href='#issue-44'>#</a></span>
<span>Summary:  Should start/end of scroll container automatically be snap-points?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Oct/0571.html'>https://lists.w3.org/Archives/Public/www-style/2013Oct/0571.html</a> (tab)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html'>https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html</a> (roc)</span>
<span>    Maybe need implicit snap points at 0/end, but also there are use-cases for not doing it. </span>
<span>    (Using snap-points for pull-to-refresh, for example, to hide the "pulled" part initially.)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html</a></span>
<span>    Proposal for adding edges of an element's margin or border box</span>
<span>    to the list of available snap points, in <a href='https://wiki.mozilla.org/index.php?title=Gecko:CSSScrollSnapping'>https://wiki.mozilla.org/index.php?title=Gecko:CSSScrollSnapping</a></span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Aug/0397.html'>https://lists.w3.org/Archives/Public/www-style/2014Aug/0397.html</a> (ted)</span>
<span>    What to do when the end of the box isn't a snap point, and type is mandatory?</span>
<span>    Bounce, or assume there's one there anyway?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Aug/0427.html'>https://lists.w3.org/Archives/Public/www-style/2014Aug/0427.html</a> (fremy)</span>
<span>    Omitting the end can be useful to do pull-to-refresh behaviors at end.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html'>https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html</a> (TPAC 2014)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html</a> (majid)</span>
<span>    Way to make start/end of scrollable area snappable</span>
<span>    Response: (rakow) Can't see a use case -- interval syntax includes it</span>
<span>    implicitly, and for elements, there's no element there anyway</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0453.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0453.html</a></span>
<span>Note:     WebKit implicitly adds these snappoints.</span>
<span>Solution: No automatic snap points at scrollable area edges, snap to elements as necessary</span>
<span class="r">Closed:   Rejected</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' a' id='issue-45'>
<span>Issue 45. <a href='#issue-45'>#</a></span>
<span>Summary:  Independent scroll-snap-type per axis</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html</a> (Seattle F2F)</span>
<span>    different snap types in x and y dimensions</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>    Independent control of scroll-snap-type for vertical and horizontal axes</span>
<span>    is essential. Imagine, for example, you're scrolling through a vertical</span>
<span>    list of images of different sizes and some of them overflow horizontally.</span>
<span>    We want to snap to image edges when scrolling vertically but do no snapping</span>
<span>    when scrolling horizontally. With the current draft we can't do that.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html</a> (rakow)</span>
<span>    This interferes with 2D snapping</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html</a> (roc)</span>
<span>    Independent control over vert and horiz snapping is needed. </span>
<span>    (Scrolling through a vertical snapped list of items, but some might overflow.)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html</a></span>
<span>    Note: FF implements axis-separate snap-type</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Oct/0213.html'>https://lists.w3.org/Archives/Public/www-style/2015Oct/0213.html</a></span>
<span>    Requirements are threefold:</span>
<span>      1. single-axis snapping</span>
<span>      2. both-axis snapping</span>
<span>      3. 2D snapping</span>
<span>Solution: allow scroll-snap-align to specify one or both axis coordinates</span>
<span>Solution: add [ x | y | block | inline | both | point ] keywords</span>
<span class="a">Closed:   Accepted by TF</span>
<span>Resolved: <a href='https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html'>https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html</a></span></pre>
<pre class=' a' id='issue-46'>
<span>Issue 46. <a href='#issue-46'>#</a></span>
<span>Summary:  Scroll-snap-coordinate needs x/y longhands</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015May/0248.html'>https://lists.w3.org/Archives/Public/www-style/2015May/0248.html</a> (majid)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html</a> (majid)</span>
<span>Note:     FF implements axis-separate snap-type</span>
<span>Solution: scroll-snap-align / scroll-snap-area longhands</span>
<span>          <a href='http://drafts.csswg.org/css-scroll-snap/#longhands'>http://drafts.csswg.org/css-scroll-snap/#longhands</a></span>
<span class="a">Closed:   Accepted by TF</span></pre>
<pre class=' a' id='issue-47'>
<span>Issue 47. <a href='#issue-47'>#</a></span>
<span>Summary:  "scroll-snap-axis-x/y" / "scroll-snap-destination" poorly named</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>    "scroll-snap-axis-x/y" seems like a poor name for something that</span>
<span>    computes to a length value.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0000.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0000.html</a> (rakow)</span>
<span>    Renamed to "scroll-snap-destination"</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html</a> (roc)</span>
<span>    I still think that scroll-snap-coordinate and scroll-snap-destination are</span>
<span>    terrible names.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html</a> (roc)</span>
<span>    Rename scroll-snap-coordinate to scroll-snap-target.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html</a> (rakow)</span>
<span>    "target"+"destination" confusing, maybe rename both?</span>
<span>Solution: scroll-snap-align / scroll-snap-padding</span>
<span class="a">Closed:   Accepted by TF</span>
<span>Resolved: <a href='https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html'>https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html</a></span></pre>
<pre class=' a' id='issue-48'>
<span>Issue 48. <a href='#issue-48'>#</a></span>
<span>Summary:  "scroll-snap-coordinate-x/y" poorly named</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html</a> (roc)</span>
<span>    I still think that scroll-snap-coordinate and scroll-snap-destination are</span>
<span>    terrible names.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html</a></span>
<span>Solution: scroll-snap-align / scroll-snap-area</span>
<span class="a">Closed:   Accepted by TF</span>
<span>Resolved: <a href='https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html'>https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html</a></span></pre>
<pre class=' a' id='issue-49'>
<span>Issue 49. <a href='#issue-49'>#</a></span>
<span>Summary:  Initial value of "scroll-snap-coordinate-x/y" bad</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>    "scroll-snap-coordinate-x/y" has an initial value of 0px which means</span>
<span>    that by default every element's box creates a snapping position. This makes</span>
<span>    the "elements" feature unusable!</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html</a> (roc)</span>
<span>    Initial value of scroll-snap-coordinate is bad</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html</a> (rakow)</span>
<span>    Will fix</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0000.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0000.html</a> (rakow)</span>
<span>    Added 'none' as initial value</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' ' id='issue-50'>
<span>Issue 50. <a href='#issue-50'>#</a></span>
<span>Summary:  Bunch of stuff probably not needed? (not sure what stuff), need archaology</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html</a> (roc)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html</a> (rakow)</span></pre>
<pre class=' oi' id='issue-51'>
<span>Issue 51. <a href='#issue-51'>#</a></span>
<span>Summary:  Use commas in functional notation</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html</a> (roc)</span>
<span>    Why aren't we using commas to separate function parameters?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html</a> (rakow)</span>
<span>    Going with CSS conventions</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0032.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0032.html</a> (fantasai)</span>
<span>    <a href='http://wiki.csswg.org/ideas/functional-notation#general-principles'>http://wiki.csswg.org/ideas/functional-notation#general-principles</a></span>
<span class="oi">Closed:   Invalid</span></pre>
<pre class=' a' id='issue-52'>
<span>Issue 52. <a href='#issue-52'>#</a></span>
<span>Summary:  scroll-snap-points syntax needs work</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0046.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0046.html</a></span>
<span>Response: Okay</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0074.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0074.html</a></span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0075.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0075.html</a></span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0106.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0106.html</a></span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-53'>
<span>Issue 53. <a href='#issue-53'>#</a></span>
<span>Summary:  Some syntactic concerns (hyphenization, commas)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html</a> (Seattle F2F)</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-54'>
<span>Issue 54. <a href='#issue-54'>#</a></span>
<span>Summary:  Have the children determine the scroll snapping behavior (proximity, mandatory), rather than container.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html</a> (Seattle F2F)</span>
<span class="a">Closed:   Retracted</span>
<span>Resolved: TPAC 2015</span></pre>
<h2 id=scroll-snapping-behavior>Scroll Snapping Behavior</h2>
<pre class=' d' id='issue-60'>
<span>Issue 60. <a href='#issue-60'>#</a></span>
<span>Summary:  Add scroll jumping / "discrete snapping" feature</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html</a> (tab)</span>
<span>    scroll-snap needs an additional value that abruptly jumps between the</span>
<span>    snap points, rather than allowing smooth scrolling and then adjusting</span>
<span>    to a snap point (this is used by things like spreadsheets).</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Aug/0249.html'>https://lists.w3.org/Archives/Public/www-style/2013Aug/0249.html</a> (roc)</span>
<span>    Does this make sense for touch panning? I kinda doubt it does.</span>
<span>    Maybe instead whether we abruptly jump between snap points</span>
<span>    should be up to the UA and depend on the scroll mechanism?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Oct/0570.html'>https://lists.w3.org/Archives/Public/www-style/2013Oct/0570.html</a> (tab)</span>
<span>    Snap "discretely", rather than smoothly scrolling, like spreadsheets do.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html</a> (rakow)</span>
<span>    Consider a spreadsheet application, which generally snaps rows/columns</span>
<span>    consistently to the top/left edge. [Or text editor.]</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html</a> (roc)</span>
<span>    Spreadsheet scrolling behavior is evil.</span>
<span>    Text editor case is imaginary afaict.</span>
<span>Solution: Add value to scroll-snap-type? Defer? Reject?</span>
<span class="d">Closed:   Deferred</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' a' id='issue-62'>
<span>Issue 62. <a href='#issue-62'>#</a></span>
<span>Summary:  Mandatory snapping only when snap point is visible.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Apr/0103.html'>https://lists.w3.org/Archives/Public/www-style/2015Apr/0103.html</a></span>
<span>    There should be a way to specify to only snap when there’s a snappoint</span>
<span>    in the visible area of the scroll container. I’m trying to describe</span>
<span>    something which feels in-between the current [mandatory] & [proximity]</span>
<span>    values for [scroll-snap-type]. It could be named [visible]. In this</span>
<span>    case [proximity] would be too loose, but [mandatory] too strict. You</span>
<span>    don’t want to change the behavior of the current values, as they make</span>
<span>    a lot of sense in other situations. So adding a new one is my suggestion.</span>
<span class="a">Closed: Accepted</span>
<span>Note:   Waiting for clarification from OP</span></pre>
<pre class=' a' id='issue-63'>
<span>Issue 63. <a href='#issue-63'>#</a></span>
<span>Summary:  Determine snap edge by scroll direction</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0284.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0284.html</a> (roc)</span>
<span>    Propose that when doing element-snapping,</span>
<span>    automatically decide which edge to snap based on the direction you're scrolling.</span>
<span>    E.g., snap bottom edge when scrolling down.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html</a> (roc)</span>
<span>    Per-gesture snapping points (top vs bottom depending on direction)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html</a> (rakow)</span>
<span>    This is weird and bad.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html</a> (roc)</span>
<span>    Disagree, not having this is bad. But only sensible for items fully in the scrollport</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html'>https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html</a> (rakow)</span>
<span>    You're wrong, there are more use cases than that.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html</a> (roc)</span>
<span>    Okay, I'm wrong. We can agree on this now.</span>
<span class="a">Closed:   Retracted</span></pre>
<pre class=' a' id='issue-64'>
<span>Issue 64. <a href='#issue-64'>#</a></span>
<span>Summary:  Specify whether inertia can skip snap positions</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html'>https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html</a> (TPAC 2014)</span>
<span>Solution: Make skipping the default, add scroll-snap-stop property for control.</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-65'>
<span>Issue 65. <a href='#issue-65'>#</a></span>
<span>Summary:  "snap points" is a misleading term</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html'>https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html</a> (roc)</span>
<span>    I think the terminology "snap points" can be misleading. You don't snap to</span>
<span>    Cartesian points, you snap to horizontal or vertical lines/edges. I suggest</span>
<span>    renaming everything to not refer to points. "Positions" might be better.</span>
<span>Solution: Using "snap positions"</span>
<span class="a">Closed:   Accepted by TF</span></pre>
<pre class=' a' id='issue-66'>
<span>Issue 66. <a href='#issue-66'>#</a></span>
<span>Summary:  Make sure zooming doesn't interfere with snapping, or make it act in a weird/unpredictable manner.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html</a> (Seattle F2F)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html</a> (rakow)</span>
<span>    Specified that visual viewport snaps, not layout viewport</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' ' id='issue-67'>
<span>Issue 67. <a href='#issue-67'>#</a></span>
<span>Summary:  2D snapping, such as cities on a map</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html</a> (rakow)</span>
<span>    Diagonally positioned snappable elements in a 2d scroller, for example snapping to center on cities on a map</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0170.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0170.html</a></span>
<span>    1D vs 2D snapping</span>
<span class="">Closed:   Accepted, marked at-risk</span></pre>
<pre class=' a' id='issue-68'>
<span>Issue 68. <a href='#issue-68'>#</a></span>
<span>Summary:  Better definition of snapping behavior</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html</a> (roc)</span>
<span>    Need more precise, consolidated definition of snapping behavior</span>
<span>Solution: "Scroll Snapping Model" and "Scroll Snapping Mechanics" sections</span>
<span class="a">Closed:   Accepted by TF</span>
<span class="a">Verified: by OP via private email</span></pre>
<pre class=' a' id='issue-69'>
<span>Issue 69. <a href='#issue-69'>#</a></span>
<span>Summary:  Define what happens when there's no snap points</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html'>https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html</a> (roc)</span>
<span>    Mandatory snapping + no snap points = problem.</span>
<span>    Suggest snapping to 0.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html</a> (roc)</span>
<span>Solution: No snapping occurs</span>
<span>          <a href='https://hg.csswg.org/drafts/diff/ee1b97add9cb/css-scroll-snap/Overview.bs'>https://hg.csswg.org/drafts/diff/ee1b97add9cb/css-scroll-snap/Overview.bs</a></span>
<span class="a">Closed:   Accepted</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' a' id='issue-70'>
<span>Issue 70. <a href='#issue-70'>#</a></span>
<span>Summary:  Define what happens when snap points cannot be satisfied without overscrolling</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html</a> (roc)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html'>https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html</a> (roc)</span>
<span>    I think it's important to soon resolve the issue about what to do for</span>
<span>    mandatory snapping when there's no reachable snappoint. I propose that if</span>
<span>    there are no reachable snappoints at all, no snapping occurs. Otherwise we</span>
<span>    scroll as far as we can to minimize the distance between the scroll</span>
<span>    position and the nearest snappoint.</span>
<span>Solution: Snap to furthest valid scroll position</span>
<span>          <a href='https://hg.csswg.org/drafts/diff/c283d8b6be5c/css-scroll-snap/Overview.bs'>https://hg.csswg.org/drafts/diff/c283d8b6be5c/css-scroll-snap/Overview.bs</a></span>
<span>          <a href='https://hg.csswg.org/drafts/diff/a55dada6cbcb/css-scroll-snap/Overview.bs'>https://hg.csswg.org/drafts/diff/a55dada6cbcb/css-scroll-snap/Overview.bs</a></span>
<span class="a">Closed:   Accepted by TF</span></pre>
<pre class=' a' id='issue-71'>
<span>Issue 71. <a href='#issue-71'>#</a></span>
<span>Summary:  Define what happens with snap points outside of scrollable area</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Aug/0000.html'>https://lists.w3.org/Archives/Public/www-style/2015Aug/0000.html</a></span>
<span>    How should we react to a snappoint outside the scrollable area?</span>
<span>    MS seems to consider it "invalid", </span>
<span>    Safari keeps it choosable and scrolls as close as possible if it's chosen.</span>
<span>    (Consider behavior when an element moves and its corresponding snappoint shifts slightly outside the scrollable area.)</span>
<span>Solution: Specified that scroll-snap-points-x/y don't generate more than one repetition outside scrollable area;</span>
<span>          Handle out-of-range snap positions as above (snap to furthest possible point).</span>
<span class="a">Closed:   Accepted by TF</span></pre>
<pre class=' a' id='issue-72'>
<span>Issue 72. <a href='#issue-72'>#</a></span>
<span>Summary:  Define that snap point defined by element is triggered when targeting fragment of element</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Oct/0164.html'>https://lists.w3.org/Archives/Public/www-style/2015Oct/0164.html</a></span>
<span class="a">Closed:   Accepted by TF</span>
<span>Resolved: =WG= Discuss.</span></pre>
<h2 id=enabling-element-based-snappoints>Enabling Element-based Snappoints</h2>
<pre class=' a' id='issue-80'>
<span>Issue 80. <a href='#issue-80'>#</a></span>
<span>Summary:  Remove "scroll-snap-position-x/y:elements"</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>    Just always snap to elements (union with -position lengths)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html</a> (roc)</span>
<span>    I still think a case has not been made for scroll-snap-points-x/y to</span>
<span>    support any value other than "elements", so we should get rid of it.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html</a> (Seattle F2F)</span>
<span>    Remove the "elements" value from scroll-snap-points-x/y, and just merge the lists together.</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html</a> (rakow)</span>
<span>    Removed</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Mar/0153.html'>https://lists.w3.org/Archives/Public/www-style/2015Mar/0153.html</a></span>
<span>    Removing 'elements' keyword makes it tricky to turn snapping off</span>
<span>    Response: (rakow) Use scroll-snap-type as toggle</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Mar/0154.html'>https://lists.w3.org/Archives/Public/www-style/2015Mar/0154.html</a></span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-81'>
<span>Issue 81. <a href='#issue-81'>#</a></span>
<span>Summary:  Interaction of scroll-snap-points-x/y and element snappoints</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>    Union element-based positions and snap-points-x/y positions</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0150.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0150.html</a> (smfr)</span>
<span>    Define interaction of scroll-snap-points-x/y and scroll-snap-coordinate</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-82'>
<span>Issue 82. <a href='#issue-82'>#</a></span>
<span>Summary:  Trapping snap points</span>
<span>   <a href='https://lists.w3.org/Archives/Public/www-style/2015May/0282.html'>https://lists.w3.org/Archives/Public/www-style/2015May/0282.html</a> (NYC 2015)</span>
<span>     Elements value is needed to trap scroll-snap contributions,</span>
<span>     for cases where author decides to remove scrollability.</span>
<span>   <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0147.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0147.html</a> (smfr)</span>
<span>     Less sure about this now..</span>
<span>     Also, nested scrollers issue -- need scrollers to trap snappoints</span>
<span>   <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html</a> (majid)</span>
<span>     Separate capture from snapping</span>
<span>   <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html</a> (rakow)</span>
<span>     Need some way to specify capture, maybe "elements"?</span>
<span>   <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html</a> (majid)</span>
<span>     That doesn't prevent pass-through on scrollers. Need to be associated</span>
<span>     to nearest scrollable ancestor, but only snap if 'elements' is specified.</span>
<span>   <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0457.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0457.html</a> (rakow)</span>
<span>     * Scrollability is defined by 'auto' or 'scroll' computed value</span>
<span>     * Scrollability in an axis captures snappoints in that axis</span>
<span>     * Do we really need snapping to pass through per axis?</span>
<span>     * Priorities of nested snapping vs 2D snapping?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Oct/0211.html'>https://lists.w3.org/Archives/Public/www-style/2015Oct/0211.html</a> (fantasai + Tab)</span>
<span>     Two issues:</span>
<span>       1. Specifying that 'overflow'-based trapping either</span>
<span>          A. In both axes</span>
<span>          B. In scrollable axes</span>
<span>       2. Allowing elements that aren't scroll containers to trap snap points;</span>
<span>          suggest using 'scroll-snap-type' applied to all elements.</span>
<span>Solution: Defined that 'overflow: scroll/auto' in an axis captures snappoints either</span>
<span>          in both axes</span>
<span>Solution: Made non-none values of scroll-snap-type on an element trap snappoints</span>
<span class="a">Closed:   Accepted</span>
<span>Resolved: TPAC 2015</span></pre>
<pre class=' ' id='issue-83'>
<span>Issue 83. <a href='#issue-83'>#</a></span>
<span>Summary:  Adding back elements would make snap-points-x/y exclusive with element-based points</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html</a> (rakow)</span>
<span>    if we add back the elements value then I'd rather go back to making</span>
<span>    the elements/interval options mutually exclusive for simplicity's sake</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html</a> (majid)</span>
<span>    Are there really no merged use cases?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0453.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0453.html</a> (rakow)</span>
<span>    Can't think of a single one</span>
<span class="">Closed:   Invalid, pending #82</span></pre>
<h2 id=errors>Errors</h2>
<pre class=' a' id='issue-90'>
<span>Issue 90. <a href='#issue-90'>#</a></span>
<span>Summary:  Reference to box, doesn't say whether margin/padding/content box</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html'>https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html</a> (roc)</span>
<span>Solution: scroll-snap-area</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-91'>
<span>Issue 91. <a href='#issue-91'>#</a></span>
<span>Summary:  "leading edge" used without definition</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html'>https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html</a> (roc)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html</a> (rakow)</span>
<span>    Replaced with "start edge"</span>
<span>Solution: Using "start edge" as term</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-92'>
<span>Issue 92. <a href='#issue-92'>#</a></span>
<span>Summary:  Define behavior of repeat(0px) / repeat(-1px)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html</a> (roc)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html'>https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html</a> (rakow)</span>
<span>    Disallowed zero/negative.</span>
<span>New Issue: Restriction defines an open range, see below</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-93'>
<span>Issue 93. <a href='#issue-93'>#</a></span>
<span>Summary:  Define valid repeat() values as closed range (include 0)</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0036.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0036.html</a></span>
<span>    Handle 0 in repeat()</span>
<span>    Response: (tab) Use 1px as enforced minimum</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jul/0075.html'>https://lists.w3.org/Archives/Public/www-style/2015Jul/0075.html</a></span>
<span>Solution: Used value floored at UA-specified minimum, recommended at 1px.</span>
<span class="a">Closed:   Accepted</span></pre>
<pre class=' a' id='issue-94'>
<span>Issue 94. <a href='#issue-94'>#</a></span>
<span>Summary: What element captures abspos snappoints?</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0148.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0148.html</a> (smfr)</span>
<span>    Snap point capture should follow containing block chain</span>
<span>  <a href='https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html'>https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html</a> (rakow)</span>
<span>    Should use containing block chain, but need term...</span>
<span class="a">Closed:   Accepted</span></pre>
<script>
(function () {
	var sheet = document.styleSheets[0];
	function addCheckbox(className) {
		var element = document.querySelector('*.' + className);
		var span = document.createElement('span');
		span.innerHTML = element.innerHTML;
		element.innerHTML = null;
		var check = document.createElement('input');
		check.type = 'checkbox';
		if (className == 'open') {
			check.checked = false;
			sheet.insertRule('pre:not(.open)' + '{}', sheet.cssRules.length);
			check.onchange = function (e) {
				rule.style.display = this.checked ? 'none' : 'block';
			}
		}
		else {
			check.checked = true;
			sheet.insertRule('pre.' + className + '{}', sheet.cssRules.length);
			check.onchange = function (e) {
				rule.style.display = this.checked ? 'block' : 'none';
			}
		}
		var rule = sheet.cssRules[sheet.cssRules.length - 1];
		element.appendChild(check);
		element.appendChild(span);
	}
	['a', 'd', 'fo', 'oi', 'r', 'open'].forEach(addCheckbox);
}());
</script>
